Playlist selection for audio streaming

ABSTRACT

An example embodiment may involve determining that a client device (such as a smartphone, tablet, or in-automobile audio device) is in an automobile and that the client device has access to a playlist of audio content. Possibly based on the client device being in the automobile and having access to the playlist of audio content, the client device may request a stream of the audio content. As a consequence of making the request, the client device may receive the stream of the audio content and begin audible playout of the audio content.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of and claims priority to U.S. patentapplication Ser. No. 17/022,603, filed Sep. 16, 2020, which is herebyincorporated by reference in its entirety.

U.S. patent application Ser. No. 17/022,603 is a continuation of andclaims priority to U.S. patent application Ser. No. 16/447,496, filedJun. 20, 2019, which is hereby incorporated by reference in itsentirety.

U.S. patent application Ser. No. 16/447,496 is a continuation of andclaims priority to U.S. Pat. No. 10,372,411, filed Dec. 21, 2018, whichis hereby incorporated by reference in its entirety.

U.S. Pat. No. 10,372,411 is a continuation of and claims priority toU.S. Pat. No. 10,275,212, filed Jun. 5, 2018, which is herebyincorporated by reference in its entirety.

U.S. Pat. No. 10,275,212 is a continuation of and claims priority toU.S. Pat. No. 10,019,225, filed Dec. 21, 2016, which is herebyincorporated by reference in its entirety.

BACKGROUND

Streaming audio over a packet-switched network, such as the Internet,typically involves a client device receiving a portion of the audio,buffering that portion for playout, and playing out the buffered portionwhile receiving another portion of the audio. Streaming is typicallytriggered by a user, for instance, when the user selects particularaudio content and instructs an application to begin streaming theselected content. Doing so, however, requires the user's attention, anddoes not account for environments in which the user desires to listen tothe audio, but cannot easily perform the selection thereof.

SUMMARY

The embodiments herein disclose various mechanisms for streaming audiocontent to client devices that are in automobiles. In order tofacilitate the audio streaming, a user may select one or more streamingaudio sources using a “save to automobile” function of the clientdevice. These sources may be, for instance, audio files, links to audiofiles, web pages containing links to audio files, live streaming feeds,and so on. The selected audio sources may be compiled into a playlist bythe client device or a server device. Regardless of where it isgenerated, the playlist may be stored on the client device, a serverdevice, or both.

In one variation, the client device is a wireless communication device,such as a smartphone or tablet, capable of detecting that it is in anautomobile. When the client device detects that it is in an automobile,the client device may, based on the playlist, automatically beginstreaming audio from the selected audio sources. In another variation,the client device is an automobile that includes an in-automobile audiosystem. The in-automobile audio system may detect that the automobile isactivated, occupied, and/or in motion, download the playlist, and usethe playlist to automatically begin streaming audio from the selectedaudio sources.

Both of these variations allow the user to avoid having to instruct adevice to select and stream specific audio content while the user isdriving. As a result, the user is able to drive an automobile withoutthis distraction, but still listen to the audio content desired.

Accordingly, a first example embodiment may involve determining that aclient device (such as a smartphone, tablet, or in-automobile audiodevice) is in an automobile, and that the client device has access to aplaylist of audio content. Possibly based on the client device being inthe automobile and having access to the playlist of audio content, theclient device may request a stream of the audio content. As aconsequence of making the request, the client device may receive thestream of the audio content.

In a second example embodiment, an article of manufacture may include anon-transitory computer-readable medium, having stored thereon programinstructions that, upon execution by a computing device, cause thecomputing device to perform operations in accordance with the firstexample embodiment.

In a third example embodiment, a computing device may include at leastone processor, as well as memory and program instructions. The programinstructions may be stored in the memory, and upon execution by the atleast one processor, cause the computing device to perform operations inaccordance with the first example embodiment.

In a fourth example embodiment, a system may include various means forcarrying out each of the operations of the first example embodiment.

Although examples described herein attribute certain acts to certaindevices, any device or devices could perform those acts. For instance,some of the acts attributed to a “client device” above could beperformed by one or more different client devices and/or a serverdevice.

These as well as other embodiments, aspects, advantages, andalternatives will become apparent to those of ordinary skill in the artby reading the following detailed description, with reference whereappropriate to the accompanying drawings. Further, it should beunderstood that this summary and other descriptions and figures providedherein are intended to illustrate embodiments by way of example onlyand, as such, that numerous variations are possible. For instance,structural elements and process steps can be rearranged, combined,distributed, eliminated, or otherwise changed, while remaining withinthe scope of the embodiments as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high-level depiction of a client-server computing system,according to an example embodiment.

FIG. 2 illustrates a schematic drawing of a computing device, accordingto an example embodiment.

FIG. 3 illustrates a schematic drawing of a networked server cluster,according to an example embodiment.

FIG. 4A depicts components of an in-automobile audio system, accordingto an example embodiment.

FIG. 4B depicts components of an in-automobile audio system interactingwith a wireless communication device, according to an exampleembodiment.

FIG. 5A depicts a playlist, according to an example embodiment.

FIG. 5B is a message flow diagram depicting distribution of a playlist,as well as distribution and playout of audio files referenced by theplaylist, according to an example embodiment.

FIG. 6A is a message flow diagram depicting streaming of selected audiofiles to a client device in an automobile, according to an exampleembodiment.

FIG. 6B is a message flow diagram depicting streaming of selected audiofiles to an in-automobile audio system, according to an exampleembodiment.

FIG. 7 is a flow chart, according to an example embodiment.

DETAILED DESCRIPTION

Example methods, devices, and systems are described herein. It should beunderstood that the words “example” and “exemplary” are used herein tomean “serving as an example, instance, or illustration.” Any embodimentor feature described herein as being an “example” or “exemplary” is notnecessarily to be construed as preferred or advantageous over otherembodiments or features. Other embodiments can be utilized, and otherchanges can be made, without departing from the scope of the subjectmatter presented herein.

Thus, the example embodiments described herein are not meant to belimiting. It will be readily understood that the aspects of the presentdisclosure, as generally described herein, and illustrated in thefigures, can be arranged, substituted, combined, separated, and designedin a wide variety of different configurations. For instance, steps,blocks, or acts assigned to a particular device (e.g., a server device)may be carried out by components of another device (e.g., a clientdevice) in alternative embodiments.

Further, unless context suggests otherwise, the features illustrated ineach of the figures may be used in combination with one another. Thus,the figures should be generally viewed as component aspects of one ormore overall embodiments, with the understanding that not allillustrated features are necessary for each embodiment.

Additionally, any enumeration of elements, blocks, or steps in thisspecification or the claims is for purpose of clarity. Thus, suchenumeration should not be interpreted to require or imply that theseelements, blocks, or steps adhere to a particular arrangement or arecarried out in a particular order.

1. Overview

As noted above, the embodiments herein provide for streaming of audiofiles to client devices in an automobile. In some of these scenarios,the automobile may be in motion and the client device may detect themotion, then automatically request and play out one or more streamedaudio files. These embodiments require computer implementation and arenon-analogous to pre-Internet audio distribution techniques.

Notably, unlike traditional broadcast audio, online (e.g.,Internet-based) audio may be based on a playlist that can bepersonalized for an individual user and/or client device. For instance,based on user input, a server device may generate a playlist containinga sequence of references (e.g., uniform resource locators, or URLs) toone or more remote audio files. Such a playlist may be transmitted tothe client device. The client device may traverse the playlist,retrieving and playing out the audio files. In doing so, the clientdevice may either download one or more of the audio files (from theserver device or a different device) prior to playing them out, or mayreceive the audio files as a stream.

Herein, a download of an audio file may refer to a client deviceobtaining the entire audio file from a server device before beginning toplay out any part of the audio file. The streaming of an audio file, onthe other hand, may involve the client device receiving one portion ofthe audio file while simultaneously playing out another,previously-received, portion of the audio file. While the embodimentsherein are generally directed to streaming of audio files, they may beused for the download and subsequent playout of audio files as well.

As an example of streaming, the server device may transmit the playlistto the client device, and the client device may traverse the entries ofthe playlist. In doing so, the client device may retrieve datarepresenting each referenced audio file, and play out the audio files inaccordance with the sequence defined by the playlist. Thus, for eachreference in the sequence defined by the playlist, (i) the client devicemay transmit, to the server device (or a different device), a requestfor the referenced audio file, (ii) the server device may receive thetransmitted request, (iii) responsive to the server device receiving thetransmitted request, the server device may transmit to the client, astream of the requested audio file, (iv) the client device may beginreceiving and buffering the stream of the audio file, and (v) whilestill receiving the stream of the audio file, the client device may playout the received portion of the audio file. In this way, a user may beprovided with a substantially continuous playout of the audio filesreferenced by the playlist.

As a result of the personalization and streaming, the embodiments hereinrequire computers and computer networks. Traditional broadcasting andnewscasting systems were unable to support individual user selection ofcontent, and operated using different technology. For instance, thesetraditional systems generally involve over-the-air analog broadcastingin strict real time. The embodiments herein involve on-demandtransmission of a digital stream over a packet-switched network (such asthe Internet) to client devices. The client devices can accommodate forjitter (delay variance) in the delivery of stream through the use ofbuffering.

In some embodiments, the user may select text-based files instead ofaudio files. These selections may be provided to an automatedtext-to-speech (TTS) system that converts the text therein into audio.Alternatively, the selections may be provided to a recording studio fora verbal reading of the text into audio. The resulting audio files maybe stored and eventually streamed to client devices.

Streaming of audio files is advantageous to users in times at which theyoperate their devices in a hands-free mode. For example, if a userspends one hour driving to and from work most days, the user may wish tolisten to previously-selected audio files during this time.

Regardless of how they may be implemented, the embodiments herein maymake use of one or more computing devices. These computing devices mayinclude, for example, client devices under the control of users, andserver devices that directly or indirectly interact with the clientdevices. Such devices are described in the following section.

2. Example Computing Devices, Computing Environments, and PlayoutArrangements

FIG. 1 illustrates an example communication system 100 for carrying outone or more of the embodiments described herein. Communication system100 may include computing devices. Herein, a “computing device” mayrefer to either a client device, a server device (e.g., a stand-aloneserver computer or networked cluster of server equipment), or some othertype of computational platform.

Client device 102 may be any type of device including a personalcomputer, laptop computer, a wearable computing device, a wirelesscomputing device, a head-mountable computing device, a mobile telephone,or tablet computing device, etc., that is configured to transmit data106 to and/or receive data 108 from a server device 104 in accordancewith the embodiments described herein. For example, in FIG. 1 , clientdevice 102 may communicate with server device 104 via one or morewireline or wireless interfaces. In some cases, client device 102 andserver device 104 may communicate with one another via a local-areanetwork. Alternatively, client device 102 and server device 104 may eachreside within a different network, and may communicate via a wide-areanetwork, such as the Internet.

Client device 102 may include a user interface, a communicationinterface, a main processor, and data storage (e.g., memory). The datastorage may contain instructions executable by the main processor forcarrying out one or more operations, such as operations relating to thedata sent to, or received from, server device 104, and/or otheroperations disclosed herein. The user interface of client device 102 mayinclude buttons, a touchscreen, a microphone, and/or any other elementsfor receiving inputs, as well as a speaker, one or more displays, and/orany other elements for communicating outputs.

Server device 104 may be any entity or computing device arranged tocarry out the server operations described herein. Further, server device104 may be configured to send data 108 to and/or receive data 106 fromthe client device 102.

Data 106 and data 108 may take various forms. For example, data 106 and108 may represent packets transmitted by client device 102 or serverdevice 104, respectively, as part of one or more communication sessions.Such a communication session may include packets transmitted on asignaling plane (e.g., session setup, management, and teardownmessages), and/or packets transmitted on a media plane (e.g., text,graphics, audio, and/or video data). For instance, data 106 may includetransmissions of requests for playlists and audio file streams, whiledata 108 may include, in response to these requests, transmissions ofplaylists and audio file streams, respectively.

Regardless of the exact architecture, the operations of client device102, server device 104, as well as any other operation associated withthe architecture of FIG. 1 , can be carried out by one or more computingdevices. These computing devices may be organized in a standalonefashion, in cloud-based (networked) computing environments, or in otherarrangements.

FIG. 2 is a simplified block diagram exemplifying a computing device200, illustrating some of the components that could be included in acomputing device arranged to operate in accordance with the embodimentsherein. Example computing device 200 could be a client device, a serverdevice, or some other type of computational platform. For purpose ofsimplicity, this specification may equate computing device 200 to aserver from time to time. Nonetheless, the description of computingdevice 200 could apply to any component used for the purposes describedherein.

In this example, computing device 200 includes a processor 202, a datastorage 204, a network interface 206, and an input/output function 208,all of which may be coupled by a system bus 210 or a similar mechanism.Processor 202 can include one or more CPUs, such as one or more generalpurpose processors and/or one or more dedicated processors (e.g.,application specific integrated circuits (ASICs), digital signalprocessors (DSPs), network processors, etc.).

Data storage 204, in turn, may comprise volatile and/or non-volatiledata storage and can be integrated in whole or in part with processor202. Data storage 204 can hold program instructions, executable byprocessor 202, and data that may be manipulated by these instructions tocarry out the various methods, processes, or operations describedherein. Alternatively, these methods, processes, or operations can bedefined by hardware, firmware, and/or any combination of hardware,firmware and software.

By way of example, the data in data storage 204 may contain programinstructions, perhaps stored on a non-transitory, computer-readablemedium, executable by processor 202 to carry out any of the methods,processes, or operations disclosed in this specification or theaccompanying drawings. Data storage 204 may also contain one or moreplaylists and/or audio files possibly referred to by playlists.

Network interface 206 may take the form of a wireline connection, suchas an Ethernet, Token Ring, or T-carrier connection. Network interface206 may also take the form of a wireless connection, such as IEEE 802.11(Wifi), BLUETOOTH®, or a wide-area wireless connection. However, otherforms of physical layer connections and other types of standard orproprietary communication protocols may be used over network interface206. Furthermore, network interface 206 may comprise multiple physicalinterfaces.

Input/output function 208 may facilitate user interaction with examplecomputing device 200. Input/output function 208 may comprise multipletypes of input devices, such as a keyboard, a mouse, a touch screen, andso on. Similarly, input/output function 208 may comprise multiple typesof output devices, such as a screen, monitor, printer, or one or morelight emitting diodes (LEDs). Additionally or alternatively, examplecomputing device 200 may support remote access from another device, vianetwork interface 206 or via another interface (not shown), such as auniversal serial bus (USB) or high-definition multimedia interface(HDMI) port.

In some embodiments, one or more computing devices may be deployed in anetworked architecture. The exact physical location, connectivity, andconfiguration of the computing devices may be unknown and/or unimportantto client devices. Accordingly, the computing devices may be referred toas “cloud-based” devices that may be housed at various remote locations.

FIG. 3 depicts a cloud-based server cluster 304 in accordance with anexample embodiment. In FIG. 3 , functions of a server device, such asserver device 104 (as exemplified by computing device 200) may bedistributed between server devices 306, cluster data storage 308, andcluster routers 310, all of which may be connected by local clusternetwork 312. The number of server devices, cluster data storages, andcluster routers in server cluster 304 may depend on the computingtask(s) and/or applications assigned to server cluster 304.

For example, server devices 306 can be configured to perform variouscomputing tasks of computing device 200. Thus, computing tasks can bedistributed among one or more of server devices 306. To the extent thatthese computing tasks can be performed in parallel, such a distributionof tasks may reduce the total time to complete these tasks and return aresult. For purpose of simplicity, both server cluster 304 andindividual server devices 306 may be referred to as “a server device.”This nomenclature should be understood to imply that one or moredistinct server devices, data storage devices, and cluster routers maybe involved in server device operations.

Cluster data storage 308 may be data storage arrays that include diskarray controllers configured to manage read and write access to groupsof disk drives (e.g., hard drives with rotating platters or solid statedrives). The disk array controllers, alone or in conjunction with serverdevices 306, may also be configured to manage backup or redundant copiesof the data stored in cluster data storage 308 to protect against diskdrive failures or other types of failures that prevent one or more ofserver devices 306 from accessing units of cluster data storage 308. Asan example, cluster data storage 308 may contain one or more playlistsand/or audio files possibly referred to by playlists.

Cluster routers 310 may include networking equipment configured toprovide internal and external communications for the server clusters.For example, cluster routers 310 may include one or morepacket-switching and/or routing devices configured to provide (i)network communications between server devices 306 and cluster datastorage 308 via cluster network 312, and/or (ii) network communicationsbetween the server cluster 304 and other devices via communication link302 to network 300.

Additionally, the configuration of cluster routers 310 can be based atleast in part on the data communication requirements of server devices306 and cluster data storage 308, the latency and throughput of thelocal cluster networks 312, the latency, throughput, and cost ofcommunication link 302, and/or other factors that may contribute to thecost, speed, fault-tolerance, resiliency, efficiency and/or other designgoals of the system architecture.

As a possible example, cluster data storage 308 may include any form ofdatabase, such as a structured query language (SQL) database. Varioustypes of data structures may store the information in such a database,including but not limited to tables, arrays, lists, trees, and tuples.Furthermore, any databases in cluster data storage 308 may be monolithicor distributed across multiple physical devices.

Server devices 306 may be configured to transmit data to and receivedata from cluster data storage 308. This transmission and retrieval maytake the form of SQL queries or other types of database queries, and theoutput of such queries, respectively. Additional text, images, video,and/or audio may be included as well. Furthermore, server devices 306may organize the received data into web page representations. Such arepresentation may take the form of a markup language, such as thehypertext markup language (HTML), the extensible markup language (XML),or some other standardized or proprietary format. Moreover, serverdevices 306 may have the capability of executing various types ofcomputerized scripting languages, such as but not limited to Perl,Python, PHP Hypertext Preprocessor (PHP), Active Server Pages (ASP),JavaScript, and so on. Computer program code written in these languagesmay facilitate the providing of web pages and media files to clientdevices, as well as client device interaction with the web pages andmedia files.

Some of the embodiments herein may involve playout of audio files(streamed or downloaded) by way of an in-automobile audio system. FIGS.4A and 4B depict examples of such an arrangement.

FIG. 4A includes automobile 400 equipped with in-automobile audio system402. The latter contains one or more instances of a speaker 402A, a userinterface 402B, and a communication unit 402C. In-automobile audiosystem 402 may include additional components not depicted in FIG. 4A,such as processors, memory, decoders, and so on.

Speaker 402A may include any mechanism for converting digital signalsinto audio output. User interface 402B may include, for instance, atouchscreen through which in-automobile audio system 402 can becontrolled. Communication unit 402C may include one or more wirelesscommunication interfaces through which in-automobile audio system 402can communicate with a packet-switched network, of which Internet 404 isan example.

In the embodiment of FIG. 4A, in-automobile audio system 402 may requestand receive, by way of communication unit 402C, streams or downloads ofaudio files from Internet 404. In-automobile audio system 402 may playout these audio files through speaker 402A. User interface 402B may beused to set up, modify, or terminate such a configuration.

FIG. 4B also includes automobile 400 equipped with in-automobile audiosystem 402. But, in this depiction, communication unit 402C ofin-automobile audio system 402 communicates with local communicationunit 406A of wireless communication device 406. Remote communicationunit 406C of wireless communication device 406, in turn, communicateswith Internet 404. Wireless communication device 406 may be, forexample, a smartphone, tablet, or another type of network-enabledportable computer.

The link between communication unit 402C and local communication unit406A may be either wired or wireless. For instance, this link may be aUSB cable connecting communication unit 402C and local communicationunit 406A or a BLUETOOTH® association between these units.

In some embodiments, in-automobile audio system 402 may be configured(perhaps by way of user interface 402B) to play out audio provided to itby wireless communication device 406. Wireless communication device 406may be configured (perhaps by way of user interface 406B) to download orstream audio files by way of Internet 404. Thus, streaming audio may betransmitted by a server device (e.g., server cluster 304) accessible viaInternet 404, received by wireless communication device 406, and relayedor retransmitted to in-automobile audio system 402.

In some cases, the audio files may stream between such a server deviceand wireless communication device 406, with wireless communicationdevice 406 providing digital audio output to in-automobile audio system402. In other cases, wireless communication device 406 may download oneor more audio files from the server device, then stream these files toin-automobile audio system 402 for playout. Other arrangements mayexist.

3. Example Playlist and Streaming Environment

Once audio files are selected, the client device may generate or beprovided with a playlist of these audio files. With such a playlist, theclient device may be able to request streams of the audio files and playout these streams.

FIG. 5A depicts an example playlist 500, which contains a sequence ofreferences to audio files. Playlist 500 may take the form of a computerfile, such as a plain text file, an XML file, an HTML file, a binaryfile, or some other file format. Playlists may take other forms as well,and may contain other types of content. Each entry in playlist 500 mayinclude an identifier of an audio file and/or a reference to the audiofile. Audio files referred to in playlist 500 may be stored in audiodatabase(s) 502.

In addition to the audio files selected by a user, database(s) 502 mayinclude other audio files that contain musical interludes. In generatedplaylists, zero or more musical interludes may be placed between eachpair of audio files. The musical interludes may be short piece of musicthat may serve as a break between audio files. For instance, when theplaylist contains at least some spoken word audio (e.g., news, sports,weather), musical interludes therebetween signal a change of topic tothe user. Musical interludes are optional and need not appear in aplaylist.

Nonetheless, the referenced audio file 1 in playlist 500 contains a URLthat points to the location of the audio file for article 1, while thereferenced musical interlude 1 in playlist 500 contains a URL thatpoints to the location of the audio file for musical interlude 1, and soon. Nonetheless, playlists may take other forms, such as sequences offiles.

In general, audio database(s) 502 may contains hundreds, thousands, tensof thousands, or even more audio files. Thus, audio database(s) 502 mayrepresent one or more physical devices that store these files. Suchphysical devices may be located in the same physical location, or may bedistributed over a communication network (e.g., the Internet). In somecases, the audio files may be obtained via a third-party file downloador streaming service.

Playlist 500 contains references to five audio files that are roughlyinterleaved with references to four musical interludes. A playlist maycontain more or fewer entries, however. Additionally, the patterns ofaudio files and musical interludes may vary. In some cases, a playlistmay predominately contain references to audio files with few referencesto musical interludes, and in other cases a playlist may predominatelycontain references to musical interludes with few references to audiofiles. As noted above, the musical interludes may exist as audio filesthat are separate from the audio files selected by the user.

FIG. 5B is a message flow diagram 504 depicting an example distributionof a playlist. Message flow diagram 504 includes client device 102,server device 104, and audio database(s) 502. In some embodiments, oneor more of server device 104 and audio database(s) 502 may be combinedinto fewer components or divided into more components. For instance,server device 104 may contain the functionality of audio database(s)502. Other arrangements are possible.

Client device 102 may include an audio player application that canrequest playlists, load playlists, parse playlists, and/or requeststreams of audio files referenced in playlists. In some embodiments, theaudio player application may be triggered to begin requesting andstreaming the audio files by reception of a playlist.

At step 510, client device 102 may transmit a playlist request to serverdevice 104. Here, it is assumed that server device 104, or some otherdevice, has generated a playlist based on one or more audio files to bestreamed to client device 102, or has the ability to generate orotherwise obtain the playlist if the playlist is not immediatelyavailable. Thus, at step 512, server device 104 may generate or obtainthe playlist. At step 514, server device 104 may transmit arepresentation of the playlist to client device 102. As was discussed inthe context of FIG. 5A, the playlist may include a sequence ofreferences to audio files stored in audio database(s) 502.

At step 516, client device 102 may transmit, to audio database(s) 502, arequest for the nth entry of the playlist. For instance, client device102 may parse the playlist, determine the URL of the nth entry, andrequest the content at that URL from audio database(s) 502. In response,at step 518, audio database(s) 502 may start transmitting, to clientdevice 102, a stream of the audio file associated with this entry. Then,at step 520, client device 102 may play out the stream.

Notably, client device 102 may receive and buffer a portion of thestream (e.g., 5-10 seconds) before beginning playout of the stream. Inthis way, if there is jitter in the delivery of subsequent portions ofthe stream to client device 102, this jitter may be hidden from the userby the buffering of the stream. Client device 102 may seek to maintainsuch buffering through playout of all audio files.

At step 522, client device 102 may transmit, to audio database(s) 502, arequest for the (n+1)th entry of the playlist. Client device 102 maytransmit this request while still playing out a portion of the audiofile associated with the nth entry. In this manner, client device 102may be able to transition smoothly from playout of the audio fileassociated with the nth entry to playout of the audio file associatedwith the (n+1)th entry. For instance, the audio player application mayfade out the end of the audio file associated with the nth entry whilefading in the beginning of the audio file associated with the (n+1)thentry.

Regardless, at step 524, audio database(s) 502 may start transmitting,to client device 102, a stream of the audio file associated with the(n+1)th entry. The beginning of this stream may coincide with (e.g.,directly follow) the end of the streaming of the audio file associatedwith the nth entry. Or, the streaming of these two audio files mayoverlap to some extent. Then, at step 526, client device 102 may playout the stream.

FIGS. 5A and 5B are just example embodiments of playlist generation andaudio file streaming. Other embodiments may be used to achieve the sameor similar outcomes.

4. Example Operations

FIGS. 6A and 6B depict message flow diagrams in accordance with exampleembodiments. Message flow diagram 600 of FIG. 6A depicts in-automobiledetection by a client device, and subsequent streaming of pre-selectedaudio files to that client device. The transaction therein involvesclient device 102, profile server device 602, and one or more audioservers 604.

At step 606, a user may instruct client device 102 to perform one ormore “save to automobile” operations. Each such operation triggersclient device 102 to save text, links, or other data related to one ormore audio files that can be streamed at a later time. For instance, theuser might be browsing web sites by way of a web browser. The webbrowser may have a user interface function (e.g., a button or anothertype of selector) that acts to store a reference to stream-able audiocontent on a web site. By activating this function, the reference may bestored locally on client device 102. Other applications, such as mediaplayers, email applications, social media applications, and/or games mayhave similar “save to automobile” abilities.

At step 608, one or more references saved in this fashion may betransmitted to profile server device 602. Profile server device 602 maybe a remote server (e.g., a cloud-based server) that has access to auser profile associated with client device 102. Among other things,profile server device 602 may store information related to a user ofclient device 102, including a list of one or more references to audiofiles that were generated from use of a “save to automobile” operation.

At step 610, profile server device 602 may generate a playlist includingat least some of the one or more references transmitted at step 608.This playlist may include, for instance, an ordering of URLs thatreference audio files.

At step 612, which may take place seconds, minutes, hours, or days afterstep 610, client device 102 may detect that it is in an automobile. Thisdetection may take place in numerous ways. In some examples, clientdevice 102 may be plugged in to (e.g., via a USB cable), or otherwiseassociated with (e.g., via BLUETOOTH®), an automobile. In some examples,client device 102 may detect that it is within range of a wirelesssignal associated with an automobile, such as a wireless access point(e.g., Wi-Fi). In these cases, the automobile might identify itself oversuch an interface and/or the interface may be previously associated withthe automobile (e.g., via settings in the client device 102), and clientdevice 102 may thereby determine that it is in the automobile.

Alternatively, client device 102 may make such a determinationindirectly. For instance, client device 102 may be equipped with alocation determining module, such as a global positioning system (GPS)unit. By taking two or more measurements via this module, client device102 may be able to estimate a speed at which it is moving. If this speedexceeds a particular speed threshold (e.g., 20-30 miles per hour) for aparticular time threshold (e.g., 10-20 seconds or more), client device102 may determine that it is in an automobile. In some embodiments, thisdetermination may be assisted by map data stored on or accessible toclient device 102. This map data may include locations of roads andhighways. Then, client device 102 may make a more accurate in-automobiledetermination by considering whether the speed of client device 102 issufficiently high, as well as whether client device has been travellingon roads or highways. In this fashion, client device 102 may be able todifferentiate between being in an automobile versus being carried by anindividual who is walking or riding a bike.

In-automobile detection on a client device may be assisted by anapplication programming interface (API) that allows applicationsoperating on the client device to query the operating system or alibrary of the client device as to whether the client device is in anautomobile. The operating system or library might carry out any of theactions described above to detect whether the client device is in anautomobile and then provide a response to the application.Alternatively, manual setting of client device 102 to an “in-automobile”mode may be possible.

At step 614, which may be performed in response to the in-automobiledetection of step 612, client device 102 may request a playlist fromprofile server device 602. At step 616, profile server device 602 mayresponsively transmit a copy of the playlist to client device 102. Theplaylist may contain references to the audio files.

At step 618, client device 102 may transmit a request to audio server(s)604 for the streaming of the audio files. At step 620, audio server(s)604 may begin transmitting the stream of one of the requested audiofiles to client device 102. After receiving at least a portion of thisstream, client device 102 may buffer and then audibly play out thestream.

In some embodiments, steps 618 and 620 may include one or moreadditional sub-steps in accordance with the streaming shown in messageflow diagram 504. For instance, client device 102 may sequentiallyrequest the stream of multiple audio files from two or more of audioserver(s) 604.

The ordering of the steps in FIG. 6A is for purpose of example, andother orderings exist. For instance, step 610 may occur in response tostep 614—that is, profile server device 602 may generate a playlist inresponse to receiving a request for such a playlist. In otherembodiments, steps 614 and 616 may take place prior to step 612. Inother words, profile server device 602 may generate and transmit theplaylist to client device 102 before client device 102 detects that itis in an automobile. In such an embodiment, step 614 might not benecessary, as profile server device 602 may automatically transmit theplaylist to client device 102 after the playlist is generated. Further,any of steps 606, 608, 610, 614, and 616 may occur multiple times, withprofile server device 602 adding one or more references to the playlisteach time.

Additionally, and not shown in FIG. 6A, client device 102 may transmitan indication to profile server device 602 after playing out one or moreaudio files. This indication may specify the references of one or moreaudio files that have been played out, so that profile server device 602can remove these files from the playlist. Alternatively, client device102 may update its copy of the playlist by removing these references,and transmit the updated playlist to profile server device 602.

Message flow diagram 630 of FIG. 6B depicts in-automobile detection byan automobile and subsequent streaming of pre-selected audio files to anin-automobile audio system. The transaction involves client device 102,automobile 632, profile server device 602, and one or more audio servers604.

At step 634, a user may instruct client device 102 to perform one ormore “save to automobile” operations. These operations may take place asdescribed in the context of step 606.

At step 636, one or more references saved in this fashion may betransmitted to profile server device 602. These operations may takeplace as described in the context of step 608.

At step 638, profile server device 602 may generate a playlist includingat least some of the one or more references transmitted at step 636.These operations may take place as described in the context of step 610.

At step 640, automobile 632 detects that is has been activated (e.g., byturning the ignition switch or powering on or powering up the automobileor in-automobile audio system in some fashion). Possibly in response, atstep 642, automobile 632 may request a playlist from profile serverdevice 602. At step 644, profile server device 602 may responsivelytransmit a copy of the playlist to automobile 632. The playlist maycontain references to the audio files. Alternatively, client device 102may provide the references to the audio files or the playlist directlyto automobile 632 (e.g., via USB or BLUETOOTH®), thus eliminating stepsinvolving profile server device 602.

In some cases, automobile 632 may be associated with multiple userprofiles (e.g., automobile 632 may have two or more drivers, and eachdriver may have a respective user profile accessible by profile serverdevice 602). As such, in addition to detecting that it has beenactivated, automobile 632 may also determine which particular user ofthe multiple users has activated automobile 632. Such determinationcould be made on the basis of determining which one of multiple key fobswas used to initiate activation of the automobile 632 (e.g., each one ofmultiple key fobs may be associated with a respective user); on thebasis of an estimated weight of the driver (e.g., separate driverprofiles may each be associated with a respective driver weight, andpressure sensor(s) in the driver seat may be used to estimate the weightof the driver and the estimated weight may be associated with arespective user); on the basis of a position of the driver seat (e.g.,separate driver profiles may each be associated with a respective driverseat position, and positions corresponding to those position profiles,within some tolerance, may be associated with a respective user); and/oron the basis of the presence of client device 102 within automobile 632(e.g., different users may be associated with respective client devices,and the presence of a given client device within automobile 632 asdetected via wireless signals, for example, may be associated with arespective user). In some cases, automobile 632 may provide a prompt torequest a user input to select from amongst the multiple user profilesassociated with automobile 632 (e.g., via a touch screen interfaceand/or voice interface). Moreover, indications of suchuser-distinguishing information may be transmitted to profile serverdevice 602 along with the request for a playlist (step 642), to allowprofile server device 602 to determine which user profile to access andsend its corresponding playlist back to automobile 632 (step 644).

At step 646, automobile 632 may transmit a request to audio server(s)604 for the streaming of the audio files. At step 648, audio server(s)604 may begin transmitting the stream of one of the requested audiofiles to automobile 632. After receiving at least a portion of thisstream, automobile 632 may buffer and then audibly play out the stream.

In some embodiments, steps 646 and 648 may include one or moreadditional sub-steps in accordance with the streaming shown in messageflow diagram 504. For instance, automobile 632 may sequentially requestthe stream of multiple audio files from two or more of audio server(s)604.

The ordering of the steps in FIG. 6B is for purpose of example and otherorderings exist. For instance, step 638 may occur in response to step642—that is, profile server device 602 may generate a playlist inresponse to receiving a request for such a playlist.

FIG. 7 is a flow chart illustrating an example embodiment. The processillustrated by FIG. 7 may be carried out by a client device, such ascomputing device 102. However, the process can be carried out by othertypes of devices or device subsystems, such as an automobile or anin-automobile audio system.

The embodiments of FIG. 7 may be simplified by the removal of any one ormore of the features shown therein. Further, these embodiments may becombined with one another, as well as features, aspects, and/orimplementations of any of the previous figures or otherwise describedherein. Particularly, aspects of these embodiments may be described inmore detail in the preceding specification.

A. Determining that a Client Device is in an Automobile

Block 700 may involve determining that a client device is in anautomobile. Doing so may include (i) querying, by an applicationexecuting on the client device, an interface that provides whether theclient device is estimated to be in the automobile, and (ii) receiving,by the application and via the interface, an indication that the clientdevice is estimated to be in the automobile. Alternatively, the clientdevice may make this determination based on its speed and/or location,as determined by a location determining module, and/or based onreceiving wireless signals associated with the automobile.

B. Determining that the Client Device has Access to a Playlist of AudioContent

Block 702 may involve determining that the client device has access to aplaylist of audio content. The audio content may be one or more audiofiles.

Doing so may involve determining that the client device previouslyflagged the audio content for in-automobile playout. Some embodimentsmay further involve determining weather or traffic conditions within athreshold distance of the client device, and selecting the audio contentto include information regarding the determined weather or trafficconditions. For instance, if there is a storm within 20-30 miles of theautomobile, a reference to an audio file announcing the existence and/ortrajectory of this storm may be inserted into the playlist. In thismanner, the user is warned of a potential upcoming driving impediment.If there is a traffic condition (e.g., an accident or congestion) within5-10 miles of the automobile and in the direction that the automobile isheading, a reference to an audio file announcing the existence and/orlocation of this condition may be inserted into the playlist. In thisfashion, the user may be able to plot an alternate route to avoid thecondition.

Alternatively or additionally, embodiments may also involve determininga number of humans in the automobile, and selecting the audio contentbased on the determined number of humans in the automobile. Forinstance, some automobiles include pressure sensors in one or more ofthe seats therein. Through use of the pressure sensors, the number ofhuman in the automobile can be determined, and then provided to theclient device. Based on this determination, the audio content streamedto the client device may change. For example, if there is one person inthe automobile, a default playlist may be used. But, if there is morethan one person in the automobile, a different playlist may be used, orthe playlist may be modified to include different references todifferent audio files.

C. Requesting a Stream of the Audio Content

Block 704 may involve, possibly based on the client device being in theautomobile and having access to the playlist of audio content,requesting a stream of the audio content. Doing so may include providinga visual or audible indication that the client device can play out theaudio content, and receiving a command to request the stream of audiocontent. In some embodiments, the command may be a voice command, andthe client device may perform speech recognition to decode the voicecommand.

D. Receiving the Stream of the Audio Content

Block 706 may involve receiving the stream of the audio content. Thisstreaming may occur in accordance with the embodiments of any of FIGS.4A, 4B, 5B, 6A, and 6B.

E. Causing Audible Playout of the Stream of the Audio Content

Block 708 may involve causing audible playout of the stream of the audiocontent. In some embodiments, the client device may be a wirelesscommunication device that is in communication with an audio playoutsystem of the automobile. In these embodiments, causing audible playoutof the stream of the audio content comprises may involve transmittingthe audio content to the audio playout system, wherein reception of theaudio content causes the audio playout system to play out the audiocontent. When the client device is a wireless communication device thatincludes a speaker, causing audible playout of the stream of the audiocontent may involve playing out the audio content by way of the speaker.

In alternative embodiments, the client device may be the automobile andthe automobile may include an audio playout system. In theseembodiments, causing audible playout of the stream of the audio contentmay involve providing the audio content to the audio playout system.Reception of the audio content may cause the audio playout system toplay out the audio content.

5. Conclusion

The present disclosure is not to be limited in terms of the particularembodiments described in this application, which are intended asillustrations of various aspects. Many modifications and variations canbe made without departing from its scope, as will be apparent to thoseskilled in the art. Functionally equivalent methods and apparatuseswithin the scope of the disclosure, in addition to those enumeratedherein, will be apparent to those skilled in the art from the foregoingdescriptions. Such modifications and variations are intended to fallwithin the scope of the appended claims. The above detailed descriptiondescribes various features and functions of the disclosed systems,devices, and methods with reference to the accompanying figures. Theexample embodiments described herein and in the figures are not meant tobe limiting. Other embodiments can be utilized, and other changes can bemade, without departing from the scope of the subject matter presentedherein. It will be readily understood that the aspects of the presentdisclosure, as generally described herein, and illustrated in thefigures, can be arranged, substituted, combined, separated, and designedin a wide variety of different configurations, all of which areexplicitly contemplated herein.

With respect to any or all of the message flow diagrams, scenarios, andflow charts in the figures and as discussed herein, each step, block,and/or communication can represent a processing of information and/or atransmission of information in accordance with example embodiments.Alternative embodiments are included within the scope of these exampleembodiments. In these alternative embodiments, for example, functionsdescribed as steps, blocks, transmissions, communications, requests,responses, and/or messages can be executed out of order from that shownor discussed, including substantially concurrent or in reverse order,depending on the functionality involved. Further, more or fewer blocksand/or functions can be used with any of the ladder diagrams, scenarios,and flow charts discussed herein, and these ladder diagrams, scenarios,and flow charts can be combined with one another, in part or in whole.

A step or block that represents a processing of information cancorrespond to circuitry that can be configured to perform the specificlogical functions of a herein-described method or technique.Alternatively or additionally, a step or block that represents aprocessing of information can correspond to a module, a segment, or aportion of program code (including related data). The program code caninclude one or more instructions executable by a processor forimplementing specific logical functions or actions in the method ortechnique. The program code and/or related data can be stored on anytype of computer readable medium such as a storage device including adisk, hard drive, or other storage medium.

The computer readable medium can also include non-transitory computerreadable media such as computer-readable media that store data for shortperiods of time like register memory, processor cache, and random accessmemory (RAM). The computer readable media can also includenon-transitory computer readable media that store program code and/ordata for longer periods of time. Thus, the computer readable media mayinclude secondary or persistent long term storage, like read only memory(ROM), optical or magnetic disks, compact-disc read only memory(CD-ROM), for example. The computer readable media can also be any othervolatile or non-volatile storage systems. A computer readable medium canbe considered a computer readable storage medium, for example, or atangible storage device.

Moreover, a step or block that represents one or more informationtransmissions can correspond to information transmissions betweensoftware and/or hardware modules in the same physical device. However,other information transmissions can be between software modules and/orhardware modules in different physical devices.

The particular arrangements shown in the figures should not be viewed aslimiting. It should be understood that other embodiments can includemore or less of each element shown in a given figure. Further, some ofthe illustrated elements can be combined or omitted. Yet further, anexample embodiment can include elements that are not illustrated in thefigures.

While various aspects and embodiments have been disclosed herein, otheraspects and embodiments will be apparent to those skilled in the art.The various aspects and embodiments disclosed herein are for purpose ofillustration and are not intended to be limiting, with the true scopebeing indicated by the following claims.

What is claimed is:
 1. A method comprising: determining, by a vehicle,that the vehicle has been activated; in response to determining that thevehicle has been activated, obtaining, by the vehicle, a playlist from aclient device within the vehicle, wherein the playlist includes one ormore references indicating audio files; requesting, by the vehicle, astream of the audio files from one or more audio server devices;receiving, by the vehicle, the stream of the audio files; and causing,by the vehicle, audible playout of the stream of the audio files,wherein the client device updates the playlist by removing referencesindicating the audio files that were played out.
 2. The method of claim1, further comprising: detecting, by the vehicle, that the client deviceis within the vehicle by prompting a user to select a user profilerelated to the client device.
 3. The method of claim 1, furthercomprising: detecting, by the vehicle, that the client device is withinthe vehicle by: providing a visual or audible indication that the clientdevice can play out the audio files, and receiving a command to requestthe stream of the audio files.
 4. The method of claim 1, furthercomprising: detecting, by the vehicle, that the client device is withinthe vehicle by: querying, by an application executing on the clientdevice, an interface that provides whether the client device isestimated to be in the vehicle, and receiving, by the application andvia the interface, an indication that the client device is estimated tobe in the vehicle.
 5. The method of claim 1, further comprising:determining weather or traffic conditions within a threshold distance ofthe client device, wherein requesting the stream of the audio filescomprises requesting an audio file containing information regarding theweather or traffic conditions.
 6. The method of claim 1, wherein theplaylist includes one or more references that were saved by way of theclient device for in-vehicle playout.
 7. The method of claim 6, whereinsaving the one or more references by way of the client device forin-vehicle playout comprises: receiving, by way of a user interfacefunction of a web browser application executing on the client device,input that selects the one or more references; and in response toreceiving the input, storing the one or more references on the clientdevice.
 8. The method of claim 1, further comprising: determining anumber of humans in the vehicle, wherein requesting the stream of theaudio files comprises requesting an audio file based on the number ofhumans in the vehicle.
 9. The method of claim 1, wherein the clientdevice is a wireless communication device that is in communication withan audio playout system of the vehicle, and wherein causing audibleplayout of the stream of the audio files comprises: transmitting theaudio files to the audio playout system, wherein reception of the audiofiles causes the audio playout system to play out the audio files. 10.The method of claim 1, wherein the client device is a component of thevehicle, wherein the vehicle includes an audio playout system, andwherein causing audible playout of the stream of the audio filescomprises: providing the audio files to the audio playout system,wherein reception of the audio files causes the audio playout system toplay out the audio files.
 11. The method of claim 1, wherein the clientdevice is a wireless communication device that includes a speaker, andwherein causing audible playout of the stream of the audio filescomprises: causing, by the vehicle, playout of the stream of the audiofiles by way of the speaker of the wireless communication device.
 12. Anarticle of manufacture including a non-transitory computer-readablemedium, having stored thereon program instructions that, upon executionby a vehicle, cause the vehicle to perform operations comprising:determining that the vehicle has been activated; in response todetermining that the vehicle has been activated, obtaining a playlistfrom a client device within the vehicle, wherein the playlist includesone or more references indicating audio files; requesting a stream ofthe audio files from one or more audio server devices; receiving thestream of the audio files; and causing audible playout of the stream ofthe audio files, wherein the client device updates the playlist byremoving references indicating the audio files that were played out. 13.The article of manufacture of claim 12, the operations furthercomprising: detecting, by the vehicle, that the client device is withinthe vehicle by: providing a visual or audible indication that the clientdevice can play out the audio files, and receiving a command to requestthe stream of the audio files.
 14. The article of manufacture of claim12, the operations further comprising: detecting, by the vehicle, thatthe client device is within the vehicle by: querying, by an applicationexecuting on the client device, an interface that provides whether theclient device is estimated to be in the vehicle, and receiving, by theapplication and via the interface, an indication that the client deviceis estimated to be in the vehicle.
 15. The article of manufacture ofclaim 12, the operations further comprising: determining weather ortraffic conditions within a threshold distance of the client device,wherein requesting the stream of the audio files comprises requesting anaudio file containing information regarding the weather or trafficconditions.
 16. The article of manufacture of claim 12, wherein theplaylist includes one or more references that were saved by way of theclient device for in-vehicle playout.
 17. The article of manufacture ofclaim 16, wherein saving the one or more references by way of the clientdevice for in-vehicle playout comprises: receiving, by way of a userinterface function of a web browser application executing on the clientdevice, input that selects the one or more references; and in responseto receiving the input, storing the one or more references on the clientdevice.
 18. The article of manufacture of claim 12, the operationsfurther comprising: determining a number of humans in the vehicle,wherein requesting the stream of the audio files comprises requesting anaudio file based on the number of humans in the vehicle.
 19. The articleof manufacture of claim 12, wherein the client device is a component ofthe vehicle, wherein the vehicle includes an audio playout system, andwherein causing audible playout of the stream of the audio filescomprises: providing the audio files to the audio playout system,wherein reception of the audio files causes the audio playout system toplay out the audio files.
 20. The article of manufacture of claim 12,wherein the client device is a wireless communication device thatincludes a speaker, and wherein causing audible playout of the stream ofthe audio files comprises: causing, by the vehicle, playout of thestream of the audio files by way of the speaker of the wirelesscommunication device.